\chapter{Protocolo HTTP (\emph{Hypertext Transfer Protocol})}

O capítulo atual pretende mostrar o nascimento e as evoluções destacadas pelo surgimento da internet, partindo do seus pontos altos e escorregando
para o surgimento do protocolo HTTP. 

O protocolo se tornou indispensável para a \emph{web} e consequentemente para o cidadão moderno. A internet se tornou quase um bem vital,
e proteger esse estilo de vida envolve a proteção da internet, que a grosso modo, consiste em proteger os servidores \emph{web}. O capitulo 
atual pretende apresentar
o primeiro passo para a proteção da \emph{web}, o entendimento.

O conteúdo desse capítulo foi em grande parte baseado no livro dos autores, James F. Kurose e Keith W. Ross~\cite{kurose}, salvo referências explícitas 
no texto.

\section{Histórico}
Por volta da época de seu surgimento (década de 80), a internet era pouco conhecida fora do mundo acadêmico, seu acesso era limitado a professores de universidades,
pesquisadores e alunos. No princípio, a internet tinha finalidades limitadas e era usada basicamente para acesso remoto a outras máquinas ou servidores,
receber e transmitir notícias, e \emph{email} eletrônico. Essas funcionalidades estão presentes até hoje, porém nada disso era popular, a internet era 
quase totalmente desconhecida pelo resto da população.

Na década de 90 é que a internet começou a ser popularizar, mas por uma nova funcionalidade distinta das anteriores, a \emph{World Wide Web}. 
A \emph{World Wide Web} se tornou uma febre e mudou o padrão de vida e interação das pessoas. Começaram a surgir inúmeras empresas voltadas
para a área, e as antigas redes de dados em centro acadêmicos foram aos poucos superadas e convertidas em uma única e enorme rede de dados.

A internet cresceu bem rapidamente e teve grande aceitação pelos usuários, pode-se dizer que a internet chegou a ser a maior das invenções na área
de telecomunicações.

Muitos meios de telecomunicações surgiram durante os tempos, todos revolucionaram a sociedade em diferentes aspectos. Primeiramente surgiu o telefone,
que possibilitou a comunicação oral em tempo real entre dois indivíduos distantes, algo de cunho fantástico para época. A segunda invenção que 
impactou a sociedade foi a transmissão de rádio/televisão, a transmissão de informação por ondas eletromagnéticas surpreendeu possibilitando a 
transmissão de áudio e imagens
para a população, com muita comodidade. A mais recente invenção de telecomunicações foi a internet, diferente das outras invenções, que exigiam 
do usuário sintonizar-se em determinada hora para ter acesso a sua programação, a internet surgiu como um meio de telecomunicação sob demanda.
Um usuário pode acessar quando bem entender seu \emph{email}, suas notícias e seus sites. Através da internet também possibilitou-se um enorme fluxo 
de compartilhamento de informações, sendo fácil e acessível ao usuário postar alguma informação, fazer seu site e outros. Outra grande diferencial
da internet foi a enorme facilidade de acessibilidade pelo usuário, interfaces simples e coloridas, muitos recursos multimídia, grandes sites de busca,
navegadores de fácil manuseio entre outras.

\section{O protocolo HTTP}

A sigla do protocolo vem do inglês: \emph{Hypertext Transfer Protocol} (protocolo de transferência de hipertexto). Hypertexto é o formato usado para páginas \emph{web},
consiste de um arquivo com \emph{tags} e parâmetros, as \emph{tags} são interpretadas pelos navegadores renderizando diferentes elementos de uma página \emph{web},
\emph{links}, imagens, tabelas e outros. O protocolo HTTP é a alma da internet e consiste de como essas páginas são transferidas pela internet.

O HTTP é um protocolo de aplicação (situado na camada de aplicação do protocolo TCP/IP), consiste de especificações de como deve ser feito a comunicação
entre o servidor \emph{web} e o cliente, como devem ser as mensagens trocadas pelos dois. O servidor \emph{web} é responsável por armazenar as páginas \emph{web} e 
arquivos relacionados, o cliente é o usuário que requisita acessar uma página, uma imagem, um arquivo relacionado.

\subsection{Alguns conceitos básicos}
Uma página \emph{web} é normalmente montada e descrita em um arquivo HTML, esse arquivo é tratado como um objeto e todos as imagens, textos e arquivos 
relacionados a 
essa página são tratados como objetos também. Esses objetos são acessáveis baseados em endereços chamados URL, esses endereços geralmente são 
formados pelo 
nome do servidor seguido do endereço no servidor do objeto desejado. O arquivo HTML tem conhecimento de todos os
objetos usados por ele, por isso normalmente é necessário apenas conhecimento da URL (endereço) do arquivo HTML que irá montar a página \emph{web} desejada.

\begin{figure}[H]
\centerline{\includegraphics[scale=0.7]{figuras/URL.png}}
\caption{Imagem contendo o esquema de endereçamento URL (\emph{Uniform Resource Locator}).}
\label{fig:enderecoWeb}
\end{figure}

Um navegador é um agente do usuário para acesso a internet, ele monta e exibe as páginas \emph{web}, fornece várias funcionalidades para melhor navegação e 
faz as requisições de novas páginas ou arquivos com uma 
abstração de alto nível para os usuários. A parte de requisitar novas páginas, arquivos e enviar dados ao servidor em geral, consiste da parte cliente
da comunicação servidor-cliente necessária para uma comunicação HTTP.

O servidor \emph{web} é responsável por armazenar todos os objetos usados, e tem cada objeto designado a um endereço URL. O cliente e o servidor trocam mensagens
no formato HTTP entre si, requisitando arquivos páginas e as vezes até armazenam novos arquivos enviados pelo cliente.

\begin{figure}[H]
\centerline{\includegraphics[scale=0.4]{figuras/serverCliente.png}}
\caption{Imagem mostrando o esquema de requisições HTTP para se acessar um site.}
\label{fig:clienteServidorWeb}
\end{figure}

Todas as versões do protocolo HTTP foram implementadas para serem compatíveis com suas versões anteriores, possibilitando uma maior heterogeneidade e
compatibilidade. O protocolo é implementado em cima de um outro protocolo, TCP. O protocolo TCP garante uma conexão entre entre cliente servidor,
garantindo que todos os dados passados sejam recebidos sem perdas e em ordem pela protocolo da camada superior, camada de aplicação (protocolo HTTP).
Como o protocolo TCP garante a confiabilidade da transmissão dos dados, o HTTP não tem preocupações com perdas. Ao se acessar um site de internet o 
navegador do cliente manda uma requisição com a URL do site, o navegador então se comunica com seu \emph{socket} que cuidará que o protocolo TCP 
estabeleça uma conexão com o servidor  \emph{web}, essa conexão é feita totalmente por parte do protocolo TCP, requisições HTTP ficam limitadas a camada superior.
Depois de feita a conexão as requisições em formatos HTTP são encapsuladas em um protocolo TCP e mandadas ao servidor, o \emph{socket} do servidor
irá desencapsular a parte
TCP da mensagem, verificando se a mesma contêm a informação correta e na ordem, caso contrário o protocolo TCP por si só pede o reenvio da mensagem.
Uma vez desencapsulado os dados do protocolo TCP obtêm se a mensagem do protocolo HTTP requisitando o site da URL mencionada. O envio da resposta com
a página segue o mesmo processo.

Toda vez que o servidor \emph{web} responde a uma requisição de um cliente, ele não armazena informações sobre esse cliente. Logo, se um cliente requisita mais
de uma vez o mesmo objeto, o servidor não sabe informar se a requisição já foi atendida, a medida tomada é então reenviar o objeto. O fato dos servidores
não armazenarem informações sobre o usuário faz do HTTP um protocolo \emph{stateless} (sem estados).

\subsection{Conexões persistentes e não persistentes}
O HTTP pode usar conexões persistentes ou não-persistentes, em versões mais antigas o padrão era o uso de conexões não-persistentes, atualmente as 
conexões persistentes são o padrão.

As conexões não-persistentes têm esse nome pois as conexões estabelecidas são encerradas depois de cada requisição atendida. Tomando como exemplo, 
uma requisição de uma página \emph{web} contendo algumas imagens podemos compreender melhor seu funcionamento. Primeiramente uma conexão TCP é estabelecida,
o cliente manda a requisição com a URL da página desejada e o
servidor recebe essa requisição, acha os arquivos pedidos e manda a estrutura da página (arquivo HTML). Uma vez que o protocolo TCP confirmou a 
recepção
do arquivo a conexão é fechada. Mesmo que as imagens associadas a página não tenham sido entregues ainda a conexão já foi fechada, então para cada 
uma
das imagens (ou objetos) é necessário repetir o processo estabelecendo novas conexões. As conexões posteriores relacionadas as imagens podem ser 
realizadas em paralelo obtendo-se um maior desempenho, mas esse critério e o nível de paralelismo é exclusivo de cada navegador.

Conexões persistentes são opostas as não persistentes, reutilizam uma conexão já estabelecida para o envio de outros objetos solicitados. O fato das
conexões persistentes manterem a conexão pode parecer mais eficiente, porém tem seu contratempos. Quando uma requisição nova é feita estabelece-se uma
conexão nova e essa conexão é mantida esperando ser reaproveitada. Manter essa conexão exige armazenar variáveis TCP no servidor e no cliente, o que
pode reduzir drasticamente o desempenho do servidor, pois o mesmo está recebendo requisições de vários usuários ao mesmo tempo. Relembrando o exemplo
anterior, para fazer a mesma requisição de uma página com algumas imagens, pode-se estabelecer apenas uma conexão e enviar as requisições e receber
todos os objetos com apenas essa conexão. Com esse tipo de conexão se ganha um bom tempo reduzindo o número necessário de conexões e também pode-se
usar de paralelismo na requisição dos objetos, assim como nas conexões não-persistentes. O tempo de duração de cada conexão é estabelecida pelo 
servidor e pode ser configurável.

Ainda em conexões persistentes podemos ter conexões com \emph{pipelining} e sem \emph{pipelining}. Sem pipelining não há paralelização, requisitar 
mais de um objeto envolve requisitá-los um a um, e durante as requisições o servidor fica ocioso esperando uma nova requisição, o que consume 
recursos. Nas conexões com pipelining, o cliente não espera receber uma requisição anterior para fazer uma nova requisição. O cliente faz uma 
requisição toda vez que observa uma referência a um novo objeto, sem esperar por respostas anteriores. O servidor age da mesma forma mandando os
objetos sem esperar pela requisição dos objetos já previamente referenciados. O \emph{pipelining} com conexões persistentes se destacou por ser 
mais rápido
que os outros modelos, em média o tempo com \emph{pipelining} é perto do tempo de apenas uma requisição, sem considerar o tempo de conexão. A 
agilidade do 
\emph{pipelining}
junto com um menor tempo ocioso por parte do servidor o tornou padrão nas implementações das versões atuais do protocolo HTTP.

\subsection{Formato das requisições HTTP}

As mensagens HTTP têm formatos bem definidos que usam caracteres ASCII, por isso podem ser lidos tranquilamente, diferente de outros protocolos que 
usam cabeçalhos em bytes.

\begin{figure}[H]
\centerline{\includegraphics[scale=0.5]{figuras/GETmsg.png}}
\caption{Exemplo de uma mensagem comum do protocolo HTTP. Adaptada do livro Computer Networking: A Top-Down Approach~\cite{kurose}.}
\label{fig:msgGetHTTP}
\end{figure}

A figura ~\ref{fig:msgGetHTTP} mostra uma mensagem simples de requisição HTTP. A mensagem é toda composta de caracteres ASCII, no final de cada
linha há dois caracteres \emph{carriage return} e \emph{line feed}, e no final da mensagem há um \emph{carriage return} e \emph{line feed}
adicional. A primeira linha de uma requisição HTTP é chamada de  linha de requisição e as demais de linhas de cabeçalho. A linha de requisição
é composta de três partes separadas por espaços em branco, o campo de método, o campo de URL e o campo de versão HTTP, lembrando que versões antigas do HTTP são compatíveis com as
novas. O campo de método diz respeito a ação que será tomada pelo cliente e servidor, pode ser \emph{GET}, \emph{POST}, \emph{HEAD} e vários outros.
Em grande maioria das requisições são usados o método \emph{GET}, que corresponde a uma requisição de um objeto especificado no campo URL, no caso da
figura ~\ref{fig:msgGetHTTP} busca-se uma página \emph{web} em /somedir/page.html com o nome page.html. No campo URL não há necessidade de se colocar o nome
do servidor pois a conexão já foi estabelecida anteriormente pelo protocolo TCP, além disso o ultimo campo diz que a versão utilizada é a 1.1.

As linhas de cabeçalho tem tamanho variável contendo um campo em cada linha. Os campos variáveis 
são compostos do nome do campo, dois pontos, um espaço em branco e o valor
do campo.
Entrando nas linhas de cabeçalho, a primeira linha contém um campo \emph{Connection} com  o valor \emph{close}, esse campo diz respeito ao tipo de
conexão estabelecida, no caso o valor \emph{close} indica que a conexão deve ser fechada pois é uma conexão não-persistente. A segunda linha contém
o campo \emph{User-agent} que trás a informação de qual navegador está sendo usado pelo cliente, esse campo é importante pois o servidor pode escolher
diferentes versões do objeto solicitado para enviar dependendo do navegador. O campo \emph{Accept} serve para informar ao navegador quais tipos de
objetos o cliente é capaz de receber, no exemplo, arquivos html, gif e jpeg. Caso o cliente não seja capaz de reproduzir algum objeto, o servidor
não o envia. Por ultimo há o campo \emph{Accept-language}, que diz qual a preferência de idioma do objeto pretendido, caso não haja uma versão para
o idioma preferido um objeto no idioma padrão é enviado.

\begin{figure}[H]
\centerline{\includegraphics[scale=0.5]{figuras/httpFormat.jpeg}}
\caption{Formato padrão de uma mensagem HTTP. Adaptada do livro Computer Networking: A Top-Down Approach~\cite{kurose}.}
\label{fig:msgHTTP}
\end{figure}

A figura ~\ref{fig:msgHTTP} mostra o formato genérico de uma mensagem HTTP, o formato se encontra bem similar ao exemplo dado, porém possui um campo
extra, \emph{Entity Body}. Esse campo fica depois do \emph{line feed} adicional, e não é usado em métodos \emph{GET}, geralmente é usado em métodos
\emph{POST}. O método \emph{POST} é usado quando o cliente preenche algum tipo de formulário em uma página \emph{web} e o submete, as informações submetidas
então são enviadas no campo \emph{Entity Body}, o servidor recebe o \emph{POST} e prepara uma página de resposta baseada nas informações recebidas.
O método \emph{HEAD} é bem parecido ao método \emph{POST}, mas o servidor não retorna nenhum objeto durante a resposta, geralmente esse método é
usado para debugação.

\subsection{O formato das respostas HTTP}
Previamente foi visto o formato de como um cliente faz suas requisições HTTP, nesta subseção segue como são feitas as respostas do servidor ao cliente.

\begin{figure}[H]
\centerline{\includegraphics[scale=0.5]{figuras/GETmsg2.png}}
\caption{Exemplo de uma resposta comum do servidor \emph{web}. Adaptada do livro Computer Networking: A Top-Down Approach~\cite{kurose}.}
\label{fig:msgGetHTTP2}
\end{figure}

A figura ~\ref{fig:msgGetHTTP2} mostra uma resposta comum de um servidor \emph{web} a uma requisição, pode ser entendida como uma resposta a 
figura ~\ref{fig:msgGetHTTP}. Podem ser observadas três partes na resposta: a linha de estado, linhas de cabeçalho e o \emph{Entity Body}.

A primeira linha da resposta é a linha de estado e possui três campos, o primeiro diz a versão HTTP usada, o segundo possui um número que é código
para o estado do protocolo, o terceiro, e ultimo, corresponde a uma mensagem do servidor se referindo sobre o sucesso da requisição recebida. A resposta
usa a versão 1.1 do HTTP e o código 200 seguido do "OK" indicam que a requisição foi atendida com sucesso.

A segunda parte da resposta são as linhas de cabeçalho, a primeira linha de cabeçalho possui o campo \emph{Connection} que já foi visto na subseção
anterior. O campo seguinte, \emph{Date}, indica o dia e a hora em que a resposta foi criada e enviada pelo servidor. O campo \emph{Server} indica
qual tipo de servidor fez a resposta e sua versão, em seguida, o \emph{Last-Modified} indica a data e hora da última modificação do objeto enviado.
Por ultimo, temos os campos \emph{Content-Length} e \emph{Content-Type}, que indicam o tamanho em bytes do objeto enviado e o o tipo do objeto,
respectivamente. O \emph{Entity Body} vem em seguida e consiste do objeto em si.

O formato das mensagens de resposta HTTP são semelhantes aos de requisição, com exceção da linha de requisição que é substituída pela linha de estado,
assim como mencionado anteriormente. Foram citados alguns campos dentro das linhas de cabeçalho como exemplo, porém o real número de campos pode ser 
mais numeroso, principalmente pelo fato do HTTP 1.1 possuir uma ampla faixa de campos nas linhas de cabeçalho.


\begin{longtable}{|l|l|}
\caption{Alguns dos códigos de estados do protocolo e suas mensagens~\cite{codigosHTTP}.}
\tabularnewline
\hline
 Código	&Mensagem\\
 \hline
100 &Continue\\
101 &Switching Protocols\\
102 &Processing\\
200 &OK\\
201 &Created\\
202 &Accepted\\
203 &Non-Authoritative Information (disponível no HTTP/1.1)\\
204 &No Content\\
205 &Reset Content\\
206 &Partial Content\\
207 &Multi-Status\\
208 &Already Reported\\
226 &IM Used\\
230 &Authentication Successful\\ 
300 &Multiple Choices\\
301 &Moved Permanently\\
302 &Found\\
303 &See Other (disponível no HTTP/1.1)\\
304 &Not Modified\\
305 &Use Proxy (disponível no HTTP/1.1)\\
306 &Switch Proxy\\
307 &Temporary Redirect (disponível no HTTP/1.1)\\
308 &Permanent Redirect\\
400 &Bad Request\\
401 &Unauthorized\\
403 &Forbidden\\
404 &Not Found\\
407 &Proxy Authentication Required\\
408 &Request Timeout\\
409 &Conflict\\
423 &Locked \\
424 &Failed Dependency\\
424 &Method Failure\\
429 &Too Many Requests\\
444 &No Response\\
451 &Redirect\\
495 &Cert Error\\
496 &No Cert\\
497 &HTTP to HTTPS\\
500 &Internal Server Error\\
502 &Bad Gateway\\
503 &Service Unavailable\\
508 &Loop Detected\\
509 &Bandwidth Limit Exceeded\\
511 &Network Authentication Required\\
599 &Network connect timeout error\\
\hline
\end{longtable}

\subsection{\emph{Cookies}}
O servidores HTTP são \emph{stateless}(sem estado) o que facilita sua implementação, seu \emph{design} e uma maior eficiência. As vezes, porém, é necessário
identificar e restringir usuários, além de armazenar seus dados temporários, para isso o protocolo HTTP usa dos \emph{cookies}.

Os \emph{cookies} permitem ao servidor web monitorar seus usuários, possibilitando o bloqueio de certos usuários ou a autenticação de outros, personalização de artefatos para usuários distintos, 
entre outras coisas. Os \emph{cookies} foram definidos pela RFC 2965 ~\cite{RFC2965}, que se tornou obsoleta em 2011 pela RFC 6265~\cite{RFC6265}, a sua utilização é iniciativa do servidor, porém os cookies ficam salvos no cliente (somente se o navegador cliente estiver habilitado para usar \emph{cookies}), mas nada impede que o servidor armazene informações sobre o usuário de determinado \emph{cookie}.

\begin{table}[H]
\caption{Tipos de \emph{cookies} e suas descrições~\cite{cookies}.}
\begin{tabular}{|l|p{11cm}|}
\hline
Tipo	&Descrição	\\
\hline
Gerenciamento de sessão	&Usado para manter dados do usuário, comumente usado para ``carrinhos de compra'' online e opções de manter o usuário \emph{logado}.	\\ \hline
Personalização	&Guarda informações sobre personalização por parte do usuário, como, cores, aparências, número de resultados por página e etc...	\\ \hline
Rastreamento	&Armazena as páginas acessadas pelo usuário, servindo como um rastreador, pode ser usado para sugestões de novas páginas.	\\ 
\hline
\end{tabular}
\end{table}

O servidor web que desejar usar \emph{cookies}, coloca um argumento extra na sua reposta HTTP, com o nome \emph{Set-cookie}, o navegador do usuário então irá criar um \emph{cookie} no cliente, que guardará até 4 Kb de dados em disco, toda nova requisição do cliente irá conter um argumento extra com o nome do \emph{cookie} e seus possíveis detalhes. 
 
Supondo o seguinte exemplo, um usuário está requisitando uma página de um servidor web, em que ambos estão habilitados a usar \emph{cookies}. Primeiramente, o navegador do cliente faz um pedido normal da página web principal, o servidor responde com a página e com um argumento novo, \emph{Set-cookie}. Esse parâmetro pode possuir vários sub-parâmetros como nome, data de expiração, domínio e outros. O cliente, então, recebe a página e cria um \emph{cookie} com os sub-parâmetros enviados. Toda nova requisição feita pelo cliente irá conter um parâmetro novo, \emph{cookie}, e seus sub-parâmetros, o servidor web passa a usar as informações do \emph{cookie} e responde da forma mais adequada ao seu propósito.

\begin{figure}[H]
\centerline{\includegraphics[scale=1]{figuras/cookies.png}}
\caption{Exemplo de requisições com \emph{cookies}, entre cliente (client) e servidor web (server) ~\cite{cookieimg}.}
\label{fig:cookies}
\end{figure}

Não importando quanto tempo se passou desde a criação do \emph{cookie}, toda as novas requisições do cliente para esse mesmo servidor irão conter os \emph{cookies} e seus sub-parâmetros, contanto que suas datas de expiração sejam respeitadas. A cada resposta do servidor os sub-parâmetros dos \emph{cookies} podem ser alterados, esses subparâmetros podem conter informações sobre produtos em um \'carrinho de compras\' online, ou o plano de fundo favorito do usuário, ou apenas manter o usuário logado entre outras finalidades.

\subsection{Servidor proxy}
Um servidor \emph{proxy} ou também chamado \emph{cache Web}, é um servidor intermediário. Ele se localiza entre o servidor \emph{web} e o cliente, além disso, possui os principais artefatos acessados do servidor \emph{web} armazenados.

Toda vez que um cliente pretende requisitar algum artefato, o servidor \emph{proxy} responde em nome do servidor \emph{web}, lhe retornando o artefato solicitado. Caso o artefato não esteja disponível, o servidor \emph{proxy} requisita o artefato ao servidor \emph{web} em nome do cliente. Devido a essa característica o servidor \emph{proxy} pode ser considerado tanto cliente como servidor. 

As grandes vantagens de se usar um servidor \emph{proxy} são baseadas em maior rapidez de resposta, ao se usar o servidor, as requisições mais comuns já estão em \emph{cache} e são rapidamente atendidas, diminuindo o tempo de espera de vários usuários. Outra grande vantagem é a redução do consumo de banda interna, uma instituição que possui um servidor \emph{web} tem uma banda máxima para que sua rede interna se comunique com a internet e para que a internet acesse seu servidor. Caso essa largura de banda máxima
seja pequena, haverá congestionamento devido ao fluxo da rede interna à internet e vice-versa. O servidor \emph{proxy} diminue esse congestionamento pois o mesmo fica dividido entre o servidor \emph{proxy}, que atende as requisições quase instantâneamente, e o servidor \emph{web}. Em média um servidor \emph{proxy} atende entre 20\% e 80\% do fluxo total de requisições~\cite{kurose}, o que aliviaria um possível congestionamento de banda e economizaria custos a instituição de adiquirir uma largura de banda maior.

\begin{figure}[H]
\centerline{\includegraphics[scale=1]{figuras/proxy_caching.png}}
\caption{Exemplo de servidor \emph{proxy} com maior rapidez devido a proximidade com os clientes ~\cite{cacheweb	}.}
\label{fig:cacheWeb}
\end{figure}